Google下的这盘“小”棋
1
2008年的时候,我接触到了Google App Engine(简称GAE),它允许你用自己喜欢的语言如Java, Python来开发应用程序,然后部署到GAE上运行,完全不用考虑应用程序的伸缩问题,GAE可以帮助你从0扩展到全球规模。
你只需要关注你的业务逻辑,而无需关心底层的基础设施,也不用考虑防火墙等安全功能,并且可以按使用付费,用多少,付多少,这就是激动人心的PaaS (Platform as a Service)。
国内的新浪和百度也迅速跟随推出了自己的产品,Sina App Engine, Baidu App Engine。
事实证明,这种模式并没有发展起来,为什么呢?
市场需要的是更加“低级”的产品:计算,存储,数据库,队列,或者是虚拟机。这应该是IaaS(Infrastructure as a Service)层面的东西, 于是亚马逊的AWS反而发展起来了,吸引了很多应用程序的入驻。
大家都去用AWS,Google的Cloud该怎么办呢?
这个时候Docker出现了, Build Once , Run Anywhere , 使用Docker可以让应用程序在任何地方以相同的地方运行,因为它把代码和依赖的运行环境打包,放到了一起。
这是个非常美妙的特性,应用程序可以在服务器之间迁移,那也可以在云之间进行迁移,不用被某个云锁定了。
但是,仅仅是单个Docker是搞不了什么事情的,尤其是在微服务架构的情况下,需要很多Docker协作,编排,扩展。
于是Google下了一步棋, 搞了一个叫做Kubernetes (k8s) 的东西来做这些工作,经过一番争斗,干翻了Mesos,Swarm等竞争对手,成了事实的标准。
应用程序所需要的基础设施层被Google搞定:k8s + docker, 应用程序可以在微软的云,亚马逊的云,Google的云,IBM的云之间迁移, 只要支持k8s, 大家站在了同一起跑线上,就看谁提供的服务更稳定,更高效。
2
前面提到了微服务, 微服务想有效地运行起来,还需要很多的基础设施:服务发现,降级限流,负载均衡等等。 在这方面搞得最好的是Netflix这个网络视频点播的公司。
Netflix不但在生产环境大规模使用微服务, 还为Spring Cloud贡献了大量的、著名的开源组件,包括Eureka, Hystrix, Zuul ,Ribbon 等,可以说是功勋卓著。
在Spring Cloud似乎已经统治了微服务市场的时候,不断翻新的IT界又冒出了新的概念: Service Mesh 。
Service Mesh 说:现在在微服务的执行过程中,需要一个依赖库,实现微服务的发现,监控和保护, 这个依赖库和和业务密切绑定,例如Hystrix,Java语言写的, 别的应用想用的话还得再重复开发一份。
Service Mesh 提出了新的方式,把依赖库和业务剥离开,让业务代码清清爽爽。把依赖库的功能放到一个叫做代理的模块中,两个微服务之间不再直接通信,而是通过这个代理来通信:
这绝对是个釜底抽薪的办法,这是要革Spring Cloud的命啊!
Google趁机落子,和IBM等大佬提出了一个Service Mesh的框架,叫做Istio, 大有后来居上,收割成果之势。
除了Istio, Google还有gRPC来进行微服务之间的调用,支持多语言,多种平台,并且面向HTTP/2 (也是Google搞出来的,一会详细说)。
在跨越网络调用远程服务的时候,Python对象,Java对象,C++对象必须序列化才可以跨越网络的千山万水,可以把这些对象变成文本,如JSON/XML,还可以把变成二进制的数据。
Google提出的序列化协议是Protocol Buffers,这个序列化机制也是语言中立,平台中立的,性能高,数据传输过程中压缩得比较小。
3
从基础设施到应用框架,Google 都落下了自己的棋子,最后,Google把眼光移向了底层的通信协议。
Google先是对HTTP1.1动手,做了一个叫做SPDY协议的实验,非常成功,成为了HTTP 2的基础。
HTTP 2把基于文本的协议改成了基于二进制的,把HTTP请求和响应变成数据帧,这样就实现了多路复用:在一个TCP连接上可以“混合”着发送多个HTTP的请求和响应,效率大大提高。
(来源: https://www.slideshare.net/lmacvittie/http2-changes-everything)
然后,Google对传输层协议开刀,搞出了一个新的传输层协议QUIC,解决了TCP了诸多问题,有望把TCP给替换掉。基于QUIC,新的HTTP协议,即HTTP/3正在制定当中。
刚开始的时候我还在想,为什么是Google在折腾这些协议? 有那么多实力强大的公司,他们怎么不去做?
后来突然想到,Google干这件事情是比较合适的,因为他有浏览器Chrome,自己还提供了很多服务(Gmail,google.com....), 既然浏览器端和服务器端都掌握了,那修改一下中间的协议做做试验是很自然的事情,普通用户才不管这些,只要觉得网速变快了就行。
4
好了,Google现在搞定了基础设施(Docker+ K8s),搞定了微服务框架(gRPC+protobuf),甚至改进了底层的协议(HTTP/2 , QUIC, HTTP/3),正在用Istio对微服务的降级限流,服务发现等这些依赖库进行精准打击,有望成为下一代微服务的基础架构。
Google是在下棋吗?我也不知道,我能看到的这家公司把重要的点都给占住了,实在让人佩服。估计在相当长的一段时间内,都会对后端开发产生重大影响,甚至占据统治地位,大家可以关注一下。